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(57) A system and method for automated collection 
and analysis of regularly retrieved patient information for 
remote patient care is described. A set of collected 
measures (50) retrieved on a substantially regular basis 
is periodically received from a medical device 
(1 2,202,203,204) having a sensor for monitoring at least 
one physiological measure (71 -78,207,21 0) or quality of 
life measure (208,21 1 ) of an individual patient (1 1 ,201 ). 
The collected measures set includes individual meas- 
ures which each relate to patient information recorded 


by the medical device. The collected measures set is 
stored into a patient care record (205) for the individual 
patient within a database (1 7) organized to store one or 
more patient care records which each include a plurality 
(206,209) of the collected measures sets. One or more 
of the collected measures sets (206) in the patient care 
record for the individual patient is analyzed relative to 
one or more other collected measures sets (209) stored 
in the database to determine a patient status indicator 
(54). 
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Description 

Field of the Invention 

[0001] The present invention relates in general to au- 
tomated data collection and analysis, and, in particular, 
to a system and method for automated collection and 
analysis of regularly retrieved patient information for re- 
mote patient care. 

Background of the invention 

[0002] A broad class of medical subspecialties, in- 
cluding cardiology, endocrinology, hematology, neurol- 
ogy, gastroenterology, urology, ophthalmology, and 
otolaryngology, to name a few, rely on accurate and 
timely patient information for use in aiding health care 
providers in diagnosing and treating diseases and dis- 
orders. Often, proper medical diagnosis requires infor- 
mation on physiological events of short duration and 
sudden onset, yet these types of events are often occur 
infrequently and with little or no warning. Fortunately, 
such patient information can be obtained via external, 
implantable, cutaneous, subcutaneous, and manual 
medical devices, and combinations thereof. For exam- 
ple, in the area of ca'rdiology, implantable pulse gener- 
ators (IPGs) are commonly used to treat irregular heart- 
beats, known as arrhythmias. There are three basic 
types of IPGs. Cardiac pacemakers are used to manage 
hradycardia, an abnormally slow or irregular heartbeat. 
Bradycardia can cause symptoms such as fatigue, diz- 
ziness, and fainting. Implantable cardioverter defibrilla- 
tors (ICDs) are used to treat tachycardia, heart rhythms 
that are abnormally fast and life threatening. Tachycar- 
dia can result in sudden cardiac death (SCD). Finally, 
implantable cardiovascular monitors and therapeutic 
devices are used to monitor and treat structural prob- 
lems of the heart, such as congestive heart failure and 
rhythm problems. 

[0003] Pacemakers and ICDs, as well as other types 
of implantable and external medical devices, are 
equipped with an on-board, volatile memory in which te- 
lemetered signals can be stored for later retrieval and 
analysis. In addition, a growing class of cardiac medical 
devices, including implantable heart failure monitors, 
implantable event monitors, cardiovascular monitors, 
and therapy devices, are being used to provide similar 
stored device information. These devices are able to 
store more than thirty minutes of per heartbeat data. 
Typically, the telemetered signals can provide patient 
device information recorded on a per heartbeat, binned 
average basis, or derived basis from, for example, atrial 
electrical activity, ventricular electrical activity, minute 
ventilation, patient activity score, cardiac output score, 
mixed venous oxygen score, cardiovascular pressure 
measures, time of day, and any interventions and the 
relative success of such interventions. In addition, many 
such devices can have multiple sensors, or several de- 


vices can work together, for monitoring different sites 
within a patient's body. 

[0004] Presently, stored device information is re- 
trieved using a proprietary interrogator or programmer, 

5 often during a clinic visit or following a device event. The 
volume of data retrieved from a single device interroga- 
tion "snapshot" can be large and proper interpretation 
and analysis can require significant physician time and 
detailed subspecialty knowledge, particularly by cardi- 

w ologists and cardiac electrophysiologists. The sequen- 
tial logging and analysis of regularly scheduled interro- 
gations can create an opportunity for recognizing subtle 
and incremental changes in patient condition otherwise 
undetectable by inspection of a single "snapshot." How- 

is ever, present approaches to data interpretation and un- 
derstanding and practical limitations on time and physi- 
cian availability make such analysis impracticable. 
[0005] A prior art system for collecting and analyzing 
pacemaker and ICD telemetered signals in a clinical or 

20 office setting is the Model 9790 Programmer, manufac- 
tured by Medtronic, Inc., Minneapolis, MN. This pro- 
grammer can be used to retrieve data, such as patient 
electrocardiogram and any measured physiological 
conditions, collected by the IPG for recordation, display 

25 and printing. The retrieved data is displayed in chrono- 
logical order and analyzed by a physician. Comparable 
prior art systems are available from other IPG manufac- 
turers, such as the Model 2901 Programmer Recorder 
Monitor, manufactured by Guidant Corporation, Indian- 

30 apolis, IN, which includes a removable floppy diskette 
mechanism for patient data storage. These prior art sys- 
tems lack remote communications facilities and must be 
operated with the patient present. These systems 
present a limited analysis of the collected data based 

35 on a single device interrogation and lack the capability 
to recognize trends in the data spanning multiple epi- 
sodes over time or relative to a disease specific peer 
group. 

[0006] A prior art system for locating and communi- 
eating with a remote medical device implanted in an am- 
bulatory patient is disclosed in U.S. Patent No. 
5,752,976 ('976). The implanted device includes a te- 
lemetry transceiver for communicating data and operat- 
ing instructions between the implanted device and an 

45 external patient communications device. The communi- 
cations device includes a communication link to a re- 
mote medical support network, a global positioning sat- 
ellite receiver, and a patient activated link for permitting 
patient initiated communication with the medical support 

so network. 

[0007] Related prior art systems for remotely commu- 
nicating with and receiving telemetered signals from a 
medical device are disclosed in U.S. Patent Nos. 
5,113,869 (-869) and 5,336,245 ('245). In the '869 pat- 
55 ent, an implanted AECG monitor can be automatically 
interrogated at preset times of day to telemeter out ac- 
cumulated data to a telephonic communicator or a full 
disclosure recorder. The communicator can be automat- 
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ically triggered to establish a telephonic communication 
link and transmit the accumulated data to an office or 
clinic through a modem. In the '245 patent, telemetered 
data is downloaded to a larger capacity, external data 
recorder and is forwarded to a clinic using an auto-dialer 5 
and fax modem operating in a personal computer-based 
programmer/interrogator. However, the '976 telemetry 
transceiver, '869 communicator, and '245 programmer/ 
interrogator are limited to facilitating communication and 
transferal of downloaded patient data and do not include 
an ability to automatically track, recognize, and analyze 
trends in the data itself. 

[0008] In addition, the uses of multiple sensors situ- 
ated within a patient's body at multiple sites are dis- 
closed in U.S. Patent No. 5,040,536 ('536) and U.S. Pat- 
ent 5,987,352 ('352). In the '536 patent, an intravascular 
pressure posture detector includes at least two pressure 
sensors implanted in different places in the cardiovas- 
cular system, such that differences in pressure with 
changes in posture are differentially measurable. How- 
ever, the physiological measurements are used locally 
within the device, or in conjunction with any implantable 
device, to effect a therapeutic treatment. In the '352 pat- 
ent, an event monitor can include additional sensors for 
monitoring and recording physiological signals during 
arrhythmia and syncopal events. The recorded signals 
can be used for diagnosis, research or therapeutic 
study, although no systematic approach to analyzing 
these signals, particularly with respect to peer and gen- 
eral population groups, is presented. 
[0009] Thus, there is a need for a system and method 
for providing continuous retrieval, transferal, and auto- 
mated analysis of retrieved medical device information, 
such as telemetered signals, retrieved in general from 
a broad class of implantable and external medical de- 
vices. Preferably, the automated analysis would include 
recognising a trend indicating disease onset, progres- 
sion, regression, and status quo and determining wheth- 
er medical intervention is necessary. 
[001 0] There is a further need for a system and meth- 
od that would allow consideration of sets of collected 
measures, both actual and derived, from multiple device 
interrogations. These collected measures sets could 
then be compared and analyzed against short and long 
term periods of observation. 

[0011] There is a further need for a system and meth- 
od that would enable the measures sets for an individual 
patient to be self-referenced and cross-referenced to 
similar or dissimilar patients and to the general patient 
population. Preferably, the historical collected meas- 
ures sets of an individual patient could be compared and 
analyzed against those of other patients in general or of 
a disease specific peer group in particular. 

Summary of the Invention 

[0012] The present invention provides a system, 
method, computer program and computer readable 
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storage medium for automated collection and analysis 
of patient information retrieved from an implantable 
medical device for remote patient care, in accordance 
with the claims which follow. 

[0013] The patient device information relates to indi- 
vidual measures recorded by and retrieved from im- 
plantable medical devices, such as IPGs and monitors. 
The patient device information is received on a regular, 
e.g., daily, basis as sets of collected measures which 
are stored along with other patient records in a data- 
base. The information can be analyzed in an automated 
fashion and feedback provided to the patient at any time 
and in any location. 

[0014] An embodiment of the present invention is a 
system, method, and computer-readable storage medi- 
um holding code for automated collection and analysis 
of patient information retrieved from a medical device 
adapted to be implanted in a patient for remote patient 
care. A set of collected measures is periodically re- 
ceived from the medical device adapted to be implanted 
over a communications link which is interfaced to a net- 
work server. The collected measures set includes indi- 
vidual measures which each relate to patient informa- 
tion recorded by the medical device adapted to be im- 
planted for an individual patient. The collected meas- 
ures set is stored into a patient care record for the indi- 
vidual patient within a database server organized to 
store one or more patient care records. Each patient 
care record includes a plurality of the collected meas- 
ures sets. One or more of the collected measures sets 
in the patient care record for the individual patient is an- 
alyzed relative to one or more other collected measures 
sets stored in the database server to determine a patient 
status indicator. The patient status indicators are then 
triaged and prioritized for an appropriate level of alert 
and interaction. 

[0015] A further embodiment of the present invention 
is a system and method for automated remote patient 
care using patient information retrieved from a medical 
device adapted to be implanted in a patient. One or more 
patient care records are organized in a database with 
each patient care record including a plurality of the col- 
lected measures sets. Each collected measures set in- 
clude individual measures which each relate to patient 
information recorded by a medical device adapted to be 
implanted for an individual patient. A set of the collected 
measures periodically sent from the implantable medi- 
cal device over a communications link is received. The 
collected measures set is stored into the patient care 
record in the database for the individual patient. One or 
more of the collected measures sets in the patient care 
record for the individual patient are analyzed relative to 
one or more other collected measures sets stored in the 
patient care record of the individual patient. Feedback 
based on the analysis of the one or more collected 
measures sets is sent to the individual patient over a 
feedback communications link. 
[0016] A further embodiment of the present invention 


EP 1 057 448 A1 


15 


20 


25 


30 


35 


40 


45 


50 


3 


5 

is a system and method for automated remote patient 
care using patient information retrieved from a medical 
device adapted to he implanted in a patient. A plurality 
of patient care records is organized in a database with 
each patient care record including a plurality of the col- 5 
lected measures sets. Each collected measures set in- 
cludes individual measures which each relate to patient 
information recorded by a medical device adapted to be 
implanted for an individual patient. A set of the collected 
measures periodically sent from the implantable medi- 
cal device over a communications link is received. The 
collected measures set is stored into the patient care 
record in the database for the individual patient. One or 
more of the collected measures sets in the patient care 
record for the individual patient is analyzed relative to 
one or more other collected measures sets stored in oth- 
er patient care records in the database. Feedback 
based on the analysis of the one or more collected 
measures sets is sent to the individual patient over a 
feedback communications link. 
[001 7] A further embodiment of the present invention 
is a system and method for automated remote cardiac 
patient care using cardiovascular patient information re- 
trieved from a cardiac monitoring device adapted to be 
implanted in a patient. A set of collected cardiovascular 
measures recorded by and stored in the cardiac moni- 
toring device adapted to be implanted is retrieved on a 
substantially regular basis and the collected cardiovas- 
cular measures set are periodically communicated over 
a communications link to a centralized server. The col- 
lected cardiovascular measures set is stored into a pa- 
tient care record for the individual patient in a database 
coupled to the centralized server. A plurality of patient 
care records is organized in the database with each pa- 
tient care record including a plurality of the collected car- 
diovascular measures sets. Each collected cardiovas- 
cular measures set includes individual cardiovascular 
measures which each relate to patient information re- 
corded by the cardiac monitoring device for an individual 
patient. One or more of the collected cardiovascular 
measures sets in the patient care record for the individ- 
ual patient is analyzed relative to one or more other col- 
lected cardiovascular measures sets stored in the pa- 
tient care records in the database. Feedback based on 
the analysis of the one or more collected cardiovascular 
measures sets is sent to the individual patient over a 
feedback communications link. 
[001 8] A further embodiment of the present invention 
is a system and method for automated collection and 
analysis of regularly retrieved patient information for re- 
mote patient care. A set of collected measures retrieved 
on a substantially regular basis is periodically received 
from a medical device having a sensor for monitoring at 
least one physiological measure of an individual patient. 
The collected measures set includes individual meas- 
ures which each relate to patient information recorded 
by the medical device. The collected measures set is 
stored into a patient care record for the individual patient 


6 

within a database organized to store one or more patient 
care records which each include a plurality of the col- 
lected measures sets. One or more of the collected 
measures sets in the patient care record for the individ- 
ual patient is analyzed relative to one or more other col- 
lected measures sets stored in the database to deter- 
mine a patient status indicator.The present invention fa- 
cilitates the gathering, storage, and analysis of critical 
patient information obtained on a routine basis and an- 
alyzed in an automated manner. Thus, the burden on 
physicians and trained personnel to evaluate the vol- 
umes of information is significantly minimized while the 
benefits to patients are greatly enhanced. 
[0019] Still other embodiments of the present inven- 
tion will become readily apparent to those skilled in the 
art from the following detailed description, wherein is de- 
scribed embodiments of the invention by way of illustra- 
tion and example only. As will he realized, the invention 
is capable of other and different embodiments and its 
several details are capable of modifications in various 
obvious respects, all without departing from the scope 
of the present invention. 


Brief Description of the Drawings 

25 

]0020] 

FIGURE 1 is a block diagram showing a system for 
automated collection and analysis of patient infor- 
30 mation retrieved from an implantable medical de- 
vice for remote patient care in accordance with the 
present invention; 

FIGURE 2 is a block diagram showing the hardware 
components of the server system of the system of 
35 FIGURE 1; 

FIGURE 3 is a block diagram showing the software 
modules of the server system of the system of FIG- 
URE 1; 

FIGURE 4 is a block diagram showing the analysis 
*o module of the server system of FIGURE 3; 

FIGURE 5 is a database schema showing, by way 
of example, the organization of a cardiac patient 
care record stored in the database of the system of 
FIGURE 1; 

45 FIGURE 6 is a record view showing, by way of ex- 
ample, a set of partial cardiac patient care records 
stored in the database of the system of FIGURE 1 ; 
FIGURE 7 is a flow diagram showing a method for 
automated collection and analysis of patient infor- 
50 mation retrieved from an implantable medical de- 
vice for remote patient care in accordance with the 
present invention; 

FIGURE 8 is a flow diagram showing a routine for 
analyzing collected measures sets for use in the 
55 method of FIGURE 7; 

FIGURE 9 is a flow diagram showing a routine for 
comparing sibling collected measures sets for use 
in the routine of FIGURE 8; 
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FIGURES 10A and 1 0B are flow diagrams showing 
a routine for comparing peer collected measures 
sets for use in the routine of FIGURE 8; and 
FIGURE 11 is a flow diagram showing a routine for 
providing feedback for use in the method of FIG- 5 
URE7; 

FIGURE 12 is a block diagram showing a system 
for automated collection and analysis of regularly 
retrieved patient information for remote patient care 
in accordance with a further embodiment of the 10 
present invention; 

FIGURE 1 3 is a block diagram showing the analysis 
module of the server system of FIGURE 12; 
FIGURE 14 is a database schema showing, by way 
of example, the organization of a quality of life and is 
symptom measures set record for care of patients 
stored as part of a patient care record in the data- 
base of the system of FIGURE 12; 
FIGURE 1 5 is a record view showing, by way of ex- 
ample, a set of partial cardiac patient care records 20 
stored in the database of the system of FIGURE 1 2; 
FIGURE 16 is a Venn diagram showing, by way of 
example, peer group overlap between the partial 
patient care records of FIGURE 15; 
FIGURES 17A-17B are flow diagrams showing a 25 
method for automated collection and analysis of 
regularly retrieved patient information for remote 
patient care in accordance with a further embodi- 
ment of the present invention; and 
FIGURE 1 8 is a flow diagram showing a routine for 30 
analyzing collected measures sets for use in the 
method of FIGURES 17A-17B. 

Detailed Description 

35 

[0021] FIGURE 1 is a block diagram showing a sys- 
tem 10 for automated collection and analysis of patient 
information retrieved from an implantable medical de- 
vice for remote patient care in accordance with the 
present invention. A patient 11 is a recipient of an im- *o 
plantable medical device 12, such as, by way of exam- 
ple, an IPG or a heart failure or event monitor, with a set 
of leads extending into his or her heart. The implantable 
medical device 12 includes circuitry for recording into a 
short-term, volatile memory telemetered signals, which 45 
are stored as a set of collected measures for later re- 
trieval. 

[0022] For an exemplary cardiac implantable medical 
device, the telemetered signals non-exclusively present 
patient information relating to: atrial electrical activity, so 
ventricular electrical activity, time of day, activity level, 
cardiac output, oxygen level, cardiovascular pressure 
measures, the number and types of interventions made, 
and the relative success of any interventions made on 
a per heartbeat or binned average basis, plus the status ss 
of the batteries and programmed settings. Examples of 
pacemakers suitable for use in the present invention in- 
clude the Discovery line of pacemakers, manufactured 


by Guidant Corporation, Indianapolis, IN. Examples of 
ICDs suitable for use in the present invention include 
the Ventak line of ICDs, also manufactured by Guidant 
Corporation, Indianapolis, IN. 
[0023] In the described embodiment, the patient 11 
has a cardiac implantable medical device. However, a 
wide range of related implantable medical devices are 
used in other areas of medicine and a growing number 
of these devices are also capable of measuring and re- 
cording patient information for later retrieval. These im- 
plantable medical devices include monitoring and ther- 
apeutic devices for use in metabolism, endocrinology, 
hematology, neurology, muscularology, gastro-intesti- 
nalogy, genital-urology, ocular, auditory, and similar 
medical subspecialties. One skilled in the art would 
readily recognize the applicability of the present inven- 
tion to these related implantable medical devices. 
[0024] On a regular basis, the telemetered signals 
stored in the implantable medical device 12 are re- 
trieved. By way of example, a programmer 14 can be 
used to retrieve the telemetered signals. However, any 
form of programmer, interrogator, recorder, monitor, or 
telemetered signals transceiver suitable for communi- 
cating with an implantable medical device 1 2 could be 
used, as is known in the art. In addition, a personal com- 
puter or digital data processor could be interfaced to the 
implantable medical device 1 2, either directly or via a 
telemetered signals transceiver configured to commu- 
nicate with the implantable medical device 12. 
[0025] Using the programmer 1 4, a magnetized reed 
switch (not shown) within the implantable medical de- 
vice 12 closes in response to the placement of a wand 
13 over the location of the implantable medical device 
1 2. The programmer 1 4 communicates with the implant- 
able medical device 12 via RF signals exchanged 
through the wand 14. Programming or interrogating in- 
structions are sent to the implantable medical device 1 2 
and the stored telemetered signals are downloaded into 
the programmer 1 4. Once downloaded, the telemetered 
signals are sent via an internetwork 15, such as the In- 
ternet, to a server system 1 6 which periodically receives 
and stores the telemetered signals in a database 1 7, as 
further described below with reference to FIGURE 2. 
[0026] An example of a programmer 14 suitable for 
use in the present invention is the Model 2901 Program- 
mer Recorder Monitor, manufactured by Guidant Cor- 
poration, Indianapolis, IN, which includes the capability 
to store retrieved telemetered signals on a proprietary 
removable floppy diskette. The telemetered signals 
could later he electronically transferred using a personal 
computer or similar processing device to the internet- 
work 15, as is known in the art. 
[0027] Other alternate telemetered signals transfer 
means could also he employed. For instance, the stored 
telemetered signals could be retrieved from the implant- 
able medical device 12 and electronically transferred to 
the internetwork 15 using the combination of a remote 
external programmer and analyzer and a remote tele- 
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phonic communicator, such as described in U.S. Patent 
No. 5,113,869. Similarly, the stored telemetered signals 
could be retrieved and remotely downloaded to the serv- 
er system 1 6 using a world-wide patient location and da- 
ta telemetry system, such as described in U.S. Patent 5 
No. 5,752,976. 

[0028] The received telemetered signals are ana- 
lyzed by the server system 16, which generates a pa- 
tient status indicator. The feedback is then provided 
back to the patient 11 through a variety of means. By io 
way of example, the feedback can he sent as an elec- 
tronic mail message generated automatically by the 
server system 1 6 for transmission over the internetwork 
1 5. The electronic mail message is received by personal 
computer 1 8 (PC) situated for local access by the patient 15 
1 1 . Alternatively, the feedback can be sent through a tel- 
ephone interface device 1 9 as an automated voice mail 
message to a telephone 21 or as an automated facsimile 
message to a facsimile machine 22, both also situated 
for local access by the patient 11 . In addition to a per- 20 
sonal computer 18, telephone 21, and facsimile ma- 
chine 22, feedback could be sent to other related devic- 
es, including a network computer, wireless computer, 
personal data assistant, television, or digital data proc- 
essor. Preferably, the feedback is provided in a tiered 25 
fashion, as Jurther described below with reference to 
FIGURE 3. 

[0029] FIGURE 2 is a block diagram showing the 
hardware components of the server system 1 6 of the 
system 1 0 of FIGURE 1 . The server system 1 6 consists 30 
of three individual servers: network server 31 , database 
server 34, and application server 35. These servers are 
interconnected via an intranetwork 33. In the described 
embodiment, the functionality of the server system 16 
is distributed among these three servers for efficiency 35 
and processing speed, although the functionality could 
also be performed by a single server or cluster of serv- 
ers. The network server 31 is the primary interface of 
the server system 1 6 onto the internetwork 15. The net- 
work server 31 periodically receives the collected telem- *o 
etered signals sent by remote implantable medical de- 
vices over the internetwork 15. The network server 31 
is interfaced to the internetwork 15 through a router 32. 
To ensure reliable data exchange, the network server 
31 implements a TCP/IP protocol stack, although other 45 
forms of network protocol stacks are suitable. 
[0030] The database server 34 organizes the patient 
care records in the database 17 and provides storage 
of and access to information held in those records. A 
high volume of data in the form of collected measures so 
sets from individual patients is received. The database 
server 34 frees the network server 31 from having to 
categorize and store the individual collected measures 
sets in the appropriate patient care record. 
[0031] The application server 35 operates manage- 55 
ment applications and performs data analysis of the pa- 
tient care records, as further described below with ref- 
erence to FIGURE 3. The application server 35 commu- 


nicates feedback to the individual patients either 
through electronic mail sent back over the internetwork 
1 5 via the network server 31 or as automated voice mail 
or facsimile messages through the telephone interface 
device 19. 

[0032] The server system 1 6 also includes a plurality 
of individual workstations 36 (WS) interconnected to the 
intranetwork 33, some of which can include peripheral 
devices, such as a printer 37. The workstations 36 are 
for use by the data management and programming staff, 
nursing staff, office staff, and other consultants and au- 
thorized personnel. 

[0033] The database 17 consists of a high-capacity 
storage medium configured to store individual patient 
care records and related health care information. Pref- 
erably, the database 17 is configured as a set of high- 
speed, high capacity hard drives, such as organized into 
a Redundant Array of Inexpensive Disks (RAID) vol- 
ume. However, any form of volatile storage, non-volatile 
storage, removable storage, fixed storage, random ac- 
cess storage, sequential access storage, permanent 
storage, erasable storage, and the like would be equally 
suitable. The organization of the database 17 is further 
described below with reference to FIGURE 3. 
[0034] The individual servers and, workstations are 
general purpose, programmed digital computing devic- 
es consisting of a central processing unit (CPU), random 
access memory (RAM), non-volatile secondary storage, 
such as a hard drive or CD ROM drive, network inter- 
faces, and peripheral devices, including user interfacing 
means, such as a keyboard and display. Program code, 
including software programs, and data are loaded into 
the RAM for execution and processing by the CPU and 
results are generated for display, output, transmittal, or 
storage. In the described embodiment, the individual 
servers are Intel Pentium-based server systems, such 
as available from Dell Computers, Austin, Texas, or 
Compaq Computers, Houston, Texas. Each system is 
preferably equipped with 128MB RAM, 100GB hard 
drive capacity, data backup facilities, and related hard- 
ware for interconnection to the intranetwork 33 and in- 
ternetwork 15. In addition, the workstations 36 are also 
Intel Pentium-based personal computer or workstation 
systems, also available from Dell Computers, Austin, 
Texas, or Compaq Computers, Houston, Texas. Each 
workstation is preferably equipped with 64MB RAM, 
10GB hard drive capacity, and related hardware for in- 
terconnection to the intranetwork 33. Other types of 
server and workstation systems, including personal 
computers, minicomputers, mainframe computers, su- 
percomputers, parallel computers, workstations, digital 
data processors and the like would be equally suitable, 
as is known in the art. 

[0035] The telemetered signals are communicated 
over an internetwork 15, such as the Internet. However, 
any type of electronic communications link could he 
used, including an intranetwork link, serial link, data tel- 
ephone link, satellite link, radio-frequency link, infrared 
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link, fiber optic link, coaxial cable link, television link, and 
the like, as is known in the art. Also, the network server 
31 is interfaced to the internetwork 15 using a T-1 net- 
work router 32, such as manufactured by Cisco Sys- 
tems, Inc., San Jose, California. However, any type of 
interfacing device suitable for interconnecting a server 
to a network could be used, including a data modem, 
cable modem, network interface, serial connection, data 
port, hub, frame relay, digital PBX, and the like, as is 
known in the art. 

[0036] FIGURE 3 is a block diagram showing the soft- 
ware modules of the server system 1 6 of the system 10 
of FIGURE 1 . Each module is a computer program writ- 
ten as source code in a conventional programming lan- 
guage, such as the C or Java programming languages, 
and is presented for execution by the CPU as object or 
byte code, as is known in the arts. The various imple- 
mentations of the source code and object and byte 
codes can be held on a computer-readable storage me- 
dium or embodied on a transmission medium in a carrier 
wave. There are three basic software modules, which 
functionally define the primary operations performed by 
the server system 16: database module 51, analysis 
module 53, and feedback module 55. In the described 
embodiment, these modules are executed in a distrib- 
utea^comput[ng„environment, although a single server 
or a cluster of servers could also perform the function- 
ality of the modules. The module functions are further 
described below in more detail beginning with reference 
to FIGURE 7. 

[0037] For each patient being provided remote patient 
care, the server system 16 periodically receives a col- 
lected measures set 50 which is forwarded to the data- 
base module 51 for processing. The database module 
51 organizes the individual patent care records stored 
in the database 52 and provides the facilities for effi- 
ciently storing and accessing the collected measures 
sets 50 and patient data maintained in those records. 
An exemplary database schema for use in storing col- 
lected measures sets 50 in a patient care record is de- 
scribed below, by way of example, with reference to FIG- 
URE 5. The database server 34 (shown in FIGURE 2) 
performs the functionality of the database module 51. 
Any type of database organization could he utilized, in- 
cluding a flat file system, hierarchical database, relation- 
al database, or distributed database, such as provided 
by database vendors, such as Oracle Corporation, Red- 
wood Shores, California. 

[0038] The analysis module 53 analyzes the collected 
measures sets 50 stored in the patient care records in 
the database 52. The analysis module 53 makes an au- 
tomated determination of patient wellness in the form of 
a patient status indicator 54. Collected measures sets 
50 are periodically received from implantable medical 
devices and maintained by the database module 51 in 
the database 52. Through the use of this collected in- 
formation, the analysis module 53 can continuously fol- 
low the medical well being of a patient and can recog- 


nize any trends in the collected information that might 
warrant medical intervention. The analysis module 53 
compares individual measures and derived measures . 
obtained from both the care records for the individual 
5 patient and the care records for a disease specific group 
of patients or the patient population in general. The an- 
alytic operations performed by the analysis module 53 
are further described below with reference to FIGURE 
4. The application server 35 (shown in FIGURE 2) per- 
10 forms the functionality of the analysis module 53. 
[0039] The feedback module 55 provides automated 
feedback to the individual patient based, in part, on the 
patient status indicator 54. As described above, the 
feedback could be by electronic mail or by automated 
is voice mail or facsimile. Preferably, the feedback is pro- 
vided in a tiered manner. In the described embodiment, 
four levels of automated feedback are provided. At a first 
level, an interpretation of the patient status indicator 54 
is provided. At a second level, a notification of potential 
20 medical concern based on the patient status indicator 
54 is provided. This feedback level could also be cou- 
pled with human contact by specially trained technicians 
or medical personnel. At a third level, the notification of 
potential medical concern is forwarded to medical prac- 
titioners located in the patients geographic area. Finally, - - 
"af aTduTth level, a set of reprogramming instructions 
based on the patient status indicator 54 could be trans- 
mitted directly to the implantable medical device to mod- 
ify the programming instructions contained therein. As 
30 is customary in the medical arts, the basic tiered feed- 
back scheme would he modified in the event of bona 
fide medical emergency. The application server 35 
(shown in FIGURE 2) performs the functionality of the 
feedback module 55. 
35 [0040] FIGURE 4 is a block diagram showing the 
analysis module 53 of the server system 1 6 of FIGURE 
3. The analysis module 53 contains two functional sub- 
modules: comparison module 62 and derivation module 
63. The purpose of the comparison module 62 is to com- 
40 pare two or more individual measures, either collected 
or derived. The purpose of the derivation module 63 is 
to determine a derived measure based on one or more 
collected measures which is then used by the compar- 
ison module 62. For instance, a new and improved in- 
45 dicator of impending heart failure could be derived 
based on the exemplary cardiac collected measures set 
described with reference to FIGURE 5. The analysis 
module 53 can operate either in a hatch mode of oper- 
ation wherein patient status indicators are generated for 
so a set of individual patients or in a dynamic mode wherein 
a patient status indicator is generated on the fly for an 
individual patient. 

[0041] The comparison module 62 receives as inputs 
from the database 1 7 two input sets functionally defined 
55 as peer collected measures sets 60 and sibling collected 
measures sets 61 , although in practice, the collected 
measures sets are stored on a per sampling basis. Peer 
collected measures sets 60 contain individual collected 
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measures sets that all relate to the same type of patient 
information, for instance, atrial electrical activity, but 
which have been periodically collected over time. Sib- 
ling collected measures sets 61 contain individual col- 
lected measures sets that relate to different types of pa- 
tient information, but which may have been collected at 
the same time or different times. In practice, the collect- 
ed measures sets are not separately stored as "peer" 
and "sibling" measures. Rather, each individual patient 
care record stores multiple sets of sibling collected 
measures. The distinction between peer collected 
measures sets 60 and sibling collected measures sets 
61 is further described below with reference to FIGURE 
6. 

[0042] The derivation module 63 determines derived 
measures sets 64 on an as-needed basis in response 
to requests from the comparison module 62. The de- 
rived measures 64 are determined by performing linear 
and non-linear mathematical operations on selected 
peer measures 60 and sibling measures 61 , as is known 
in the art. 

[0043] FIGURE 5 is a database schema showing, by 
way of example, the organization of a cardiac patient 
care record stored 70 in the database 1 7 of the system 
10 of FIGURE 1. Only the information pertaining to col- 
lected measures sets are shown. Each patient care 
record would also contain normal identifying and treat- 
ment profile information, as well as medical history and 
other pertinent data (not shown). Each patient care 
record stores a multitude of collected measures sets for 
an individual patient. Each individual set represents a 
recorded snapshot of telemetered signals data which 
was recorded, for instance, per heartbeat or binned av- 
erage basis by the implantable medical device 12. For 
example, for a cardiac patient, the following information 
would be recorded as a collected measures set: atrial 
electrical activity 71 , ventricular electrical activity 72, 
time of day 73, activity level 74, cardiac output 75, oxy- 
gen level 76, cardiovascular pressure measures 77, pul- 
monary measures 78, interventions made by the im- 
plantable medical device 78, and the relative success 
of any interventions made 80. In addition, the implanta- 
ble medical device 12 would also communicate device 
specific information, including battery status 81 and pro- 
gram settings 82. Other types of collected measures are 
possible. In addition, a well-documented set of derived 
measures can be determined based on the collected 
measures, as is known in the art. 
[0044] FIGURE 6 is a record view showing, by way of 
example, a set of partial cardiac patient care records 
stored in the database 1 7 of the system 1 0 of FIGURE 
1 . Three patient care records are shown for Patient 1, 
Patient 2, and Patient 3. For each patient, three sets of 
measures are shown.X, V, and Z The measures are or- 
ganized into sets with Set 0 representing sibling meas- 
ures made at a reference time t=0. Similarly, Set n-2, 
Set n-1 and Set n each represent sibling measures 
made at later reference times t=n-2, t=n-1 and t=n, re- 


spectively. 

[0045] For a given patient, for instance, Patient 1, all 
measures representing the same type of patient infor- 
mation, such as measure X, are peer measures. These 
5 are measures, which are monitored over time in a dis- 
ease-matched peer group. All measures representing 
different types of patient information, such as measures 
X, Y, and Z, are sibling measures. These are measures 
which are also measured over time, but which might 
10 have medically significant meaning when compared to 
each other within a single set. Each of the measures, X, 
Y t and Z, could be either collected or derived measures. 
[0046] The analysis module 53 (shown in FIGURE 4) 
performs two basic forms of comparison. First, individ- 
15 ual measures for a given patient can he compared to 
other individual measures for that same patient. These 
comparisons might be peer-to-peer measures projected 
overtime, for instance, X n , X n . 1f X^.Xq, or sibling-to- 
sibling measures for a single snapshot, for instance, X n , 
20 Y w and Z n , or projected over time, for instance, X n , Y n , 
Z n , X n . 7 , Y n . v Z n . p X n . 2 , Y n „ 2 , Z n _ 2 ,-..X 0 , Y 0 , Z 0 . Second, 
individual measures for a given patient can be com- 
pared to other individual measures for a group of other 
patients sharing the same disease-specific characteris- 
es tics or to the patient population in general. Again, these 
comparisons might be peer-to-peer measures projected 
over time, for instance, X n , X n ., X n «, X n _,, X n _ r , X n . f «, 
x n-2> x n-2'> Xn-2*-' X o* x o^ x o"> or comparing the individ- 
ual patient's measures to an average from the group. 
30 Similarly, these comparisons might be sibling-to-sibling 
measures for single snapshots, for instance, X n , X nS X n -, 
Y m Y nU Y n ^ and Z n , Z n ., Z n -, or projected over time, for 
instance, X n , X n ., X n «, Y n , Y n ., V n -, Z n , Z n <, Z n «, X n . p X n . r , 

35 Y n-2> Y n-2> Y n-2 K > Z n-2> Z n-2'> ^n-2" —X 0 ,X 0 ;X 0 ; Y Qt Y 0 ; 

Y 0 ; and Z 0 , Z 0 «, Z 0 -. Other forms of comparisons are 
feasible. 

[0047] FIGURE 7 is a flow diagram showing a method 
90 for automated collection and analysis of patient in- 
40 formation retrieved from an implantable medical device 
12 for remote patient care in accordance with the 
present invention. The method 90 is implemented as a 
conventional computer program for execution by the 
server system 16 (shown in FIGURE 1). As a prepare- 
rs tory step, the patient care records are organized in the 
database 1 7 with a unique patient care record assigned 
to each individual patient (block 91 ). Next, the collected 
measures sets for an individual patient are retrieved 
from the implantable medical device 1 2 (block 92) using 
50 a programmer, interrogator, telemetered signals trans- 
ceiver, and the like. The retrieved collected measures 
sets are sent, on a substantially regular basis, over the 
internetwork 15 or similar communications link (block 
93) and periodically received by the server system 16 
55 (block 94). The collected measures sets are stored into 
the patient care record in the database 1 7 for that indi- 
vidual patient (block 95). One or more of the collected 
measures sets for that patient are analyzed (block 96), 


8 


15 


EP 1 057 448 A1 


16 


as further described below with reference to FIGURE 8. 
Finally, feedback based on the analysis is sent to that 
patient over the internetwork 15 as an email message, 
via telephone line as an automated voice mail or facsim- 
ile message, or by similar feedback communications link 
(block 97), as further described below with reference to 
FIGURE 11. 

[0048] FIGURE 8 is a flow diagram showing the rou- 
tine for analyzing collected measures sets 96 for use in 
the method of FIGURE 7. The purpose of this routine is 
to make a determination of general patient wellness 
based on comparisons and heuristic trends analyses of 
the measures, both collected and derived, in the patient 
care records in the database 1 7. A first collected meas- 
ures set is selected from a patient care record in the 
database 1 7 (block 1 00). If the measures comparison is 
to be made to other measures originating from the pa- 
tient care record for the same individual patient (block 
1 01 ), a second collected measures set is selected from 
that patient care record (block 102). Otherwise, a group 
measures comparison is being made (block 101) and a 
second collected measures set is selected from another 
patient care record in the database 1 7 (block 1 03). Note 
the second collected measures set could also contain 
averaged measures for a group of disease specific pa- 
tients or for the patient population in general. 
[0049] Next, if a sibling measures comparison is to be 
made (block 104), a routine for comparing sibling col- 
lected measures sets is performed (block 105), as fur- 
ther described below with reference to FIGURE 9. Sim- 
ilarly, if a peer measures comparison is to be made 
(block 106), a routine for comparing sibling collected 
measures sets is performed (block 107), as further de- 
scribed below with reference to FIGURES 10Aand 1 0B. 
[0050] Finally, a patient status indicator is generated 
(block 108). By way of example, cardiac output could 
ordinarily be approximately 5.0 liters per minute with a 
standard deviation of ± 1 .0. An actionable medical phe- 
nomenon could occur when the cardiac output of a pa- 
tient is ± 3.0-4.0 standard deviations out of the norm. A 
comparison of the cardiac output measures 75 (shown 
in FIGURE 5) for an individual patient against previous 
cardiac output measures 75 would establish the pres- 
ence of any type of downward health trend as to the par- 
ticular patient. A comparison of the cardiac output meas- 
ures 75 of the particular patient to the cardiac output 
measures 75 of a group of patients would establish 
whether the patient is trending out of the norm. From 
this type of analysis, the analysis module 53 generates 
a patient status indicator 54 and other metrics of patient 
wellness, as is known in the art. 
[0051] FIGURE 9 is a flow diagram showing the rou- 
tine for comparing sibling collected measures sets 105 
for use in the routine of FIGURE 8. Sibling measures 
originate from the patient care records for an individual 
patient. The purpose of this routine is either to compare 
sibling derived measures to sibling derived measures 
(blocks 1 1 1 -1 1 3) or sibling collected measures to sibling 


collected measures (blocks 115-117). Thus, if derived 
measures are being compared (block 110), measures 
are selected from each collected measures set (block 
111). First and second derived measures are derived 

5 from the selected measures (block 112) using the deri- 
vation module 63 (shown in FIGURE 4). The first and 
second derived measures are then compared (block 
113) using the comparison module 62 (also shown in 
FIGURE 4). The steps of selecting, determining, and 

10 comparing (blocks 1 1 1 -1 1 3) are repeated until no further 
comparisons are required (block 114), whereupon the 
routine returns. 

[0052] If collected measures are being compared 
(block 1 1 0), measures are selected from each collected 

is measures set (block 11 5). The first and second collected 
measures are then compared (block 1 1 6) using the com- 
parison module 62 (also shown in FIGURE 4). The steps 
of selecting and comparing (blocks 115-116) are repeat- 
ed until no further comparisons are required (block 117), 

20 whereupon the routine returns. 

[0053] FIGURES 10A and 10B are a flow diagram 
showing the routine for comparing peer collected meas- 
ures sets 107 for use in the routine of FIGURE 8. Peer 
measures originate from patient care records for differ- 

25 ent patients, including groups of disease specific pa- 
tients or the patient population in general. The purpose 
of this routine is to compare peer derived measures to 
peer derived measures (blocks 122-125), peer derived 
measures to peer collected measures (blocks 1 26-1 29), 

30 peer collected measures to peer derived measures 
(block 1 31 -1 34), or peer collected measures to peer col- 
lected measures (blocks 135-137). Thus, if the first 
measure being compared is a derived measure (block 
120) and the second measure being compared is also 

35 a derived measure (block 121), measures are selected 
from each collected measures set (block 1 22). First and 
second derived measures are derived from the selected 
measures (block 123) using the derivation module 63 
(shown in FIGURE 4). The first and second derived 

*o measures are then compared (block 124) using the 
comparison module 62 (also shown in FIGURE 4). The 
steps of selecting, determining, and comparing (blocks 
1 22-1 24) are repeated until no further comparisons are 
required (block 115), whereupon the routine returns. 

45 [0054] If the first measure being compared is a de- 
rived measure (block 120) but the second measure be- 
ing compared is a collected measure (block 1 21 ), a first 
measure is selected from the first collected measures 
set (block 1 26). A first derived measure is derived from 

so the first selected measure (block 1 27) using the deriva- 
tion module 63 (shown in FIGURE 4). The first derived 
and second collected measures are then compared 
(block 128) using the comparison module 62 (also 
shown in FIGURE 4). The steps of selecting, determin- 

55 ing, and comparing (blocks 126-128) are repeated until 
no further comparisons are required (block 1 29), where- 
upon the routine returns. 

[0055] If the first measure being compared is a col- 
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lected measure (block 1 20) but the second measure be- 
ing compared is a derived measure (block 130), a sec- 
ond measure is selected from the second collected 
measures set (block 131). A second derived measure 
is derived from the second selected measure (block 
132) using the derivation module 63 (shown in FIGURE 
4). The first collected and second derived measures are 
then compared (block 133) using the comparison mod- 
ule 62 (also shown in FIGURE 4). The steps of selecting, 
determining, and comparing (blocks 131-133) are re- 
peated until no further comparisons are required (block 
134), whereupon the routine returns. 
[0056] If the first measure being compared is a col- 
lected measure (block 120) and the second measure 
being compared is also a collected measure (block 1 30), 
measures are selected from each collected measures 
set (block 135). The first and second collected meas- 
ures are then compared (block 136) using the compar- 
ison module 62 (also shown in FIGURE 4). The steps 
of selecting and comparing (blocks 1 35-1 36) are repeat- 
ed until no further comparisons are required (block 137), 
whereupon the routine returns. 
[0057] FIGURE 11 is a flow diagram showing the rou- 
tine for providing feedback 97 for use in the method of 
FIGURE 7. The purpose of this routine is to provide 
tiered feedback based on the patient status indicator 
Four levels of feedback are provided with increasing lev- 
els of patient involvement and medical care intervention. 
At a first level (block 1 50), an interpretation of the patient 
status indicator 54, preferably phrased in lay terminolo- 
gy, and related health care information is sent to the in- 
dividual patient (block 151 ) using the feedback module 
55 (shown in FIGURE 3). At a second level (block 152), 
a notification of potential medical concern, based on the 
analysis and heuristic trends analysis, is sent to the in- 
dividual patient (block 153) using the feedback module 
55. At a third level (block 154), the notification of poten- 
tial medical concern is forwarded to the physician re- 
sponsible for the individual patient or similar health care 
professionals (block 155) using the feedback module 
55. Finally, at a fourth level (block 156), reprogramming 
instructions are sent to the implantable medical device 
12 (block 157) using the feedback module 55. 
[0058] Therefore, through the use of the collected 
measures sets, the present invention makes possible 
immediate access to expert medical care at any time 
and in any place. For example, after establishing and 
registering for each patient an appropriate baseline set 
of measures, the database server could contain a virtu- 
ally up-to-date patient history, which is available to med- 
ical providers for the remote diagnosis and prevention 
of serious illness regardless of the relative location of 
the patient or time of day 

[0059] Moreover, the gathering and storage of multi- 
ple sets of critical patient information obtained on a rou- 
tine basis makes possible treatment methodologies 
based on an algorithmic analysis of the collected data 
sets. Each successive introduction of a new collected 


measures set into the database server would help to 
continually improve the accuracy and effectiveness of 
the algorithms used. In addition, the present invention 
potentially enables the detection, prevention, and cure 
5 of previously unknown forms of disorders based on a 
trends analysis and by a cross-referencing approach to 
create continuously improving peer-group reference da- 
tabases. 

[0060] Finally, the present invention makes possible 

10 the provision of tiered patient feedback based on the au- 
tomated analysis of the collected measures sets. This 
type of feedback system is suitable for use in, for exam- 
ple, a subscription based health care service. At a basic 
level, informational feedback can be provided by way of 

is a simple interpretation of the collected data. The feed- 
back could be built up to provide a gradated response 
to the patient, for example, to notify the patient that he 
or she is trending into a potential trouble zone. Human 
interaction could be introduced, both by remotely situ- 

20 ated and local medical practitioners. Finally, the feed- 
back could include direct interventive measures, such 
as remotely reprogramming a patient's IPG. 
[0061] FIGURE 12 is a block diagram showing a sys- 
tem for automated collection and analysis of regularly 

25 retrieved patient information for remote patient care 200 
in accordance with a further embodiment of the present 
invention. The system 200 provides remote patient care 
in a manner similar to the system 10 of FIGURE 1 , but 
with additional functionality for diagnosing and monitor- 

30 jng multiple sites within a patient's body using a variety 
of patient sensors for diagnosing one or more disorder. 
The patient 201 can be the recipient of an implantable 
medical device 202, as described above, or have an ex- 
ternal medical device 203 attached, such as a Holter 

35 monitor-like device for monitoring electrocardiograms. 
In addition, one or more sites in or around the patient's 
body can be monitored using multiple sensors 204a, 
204b, such as described in U.S. Patents 4,987,897; 
5,040,536; 5, 1 1 3,859; and 5 ,987,352. Other types of de- 

40 vices with physiological measure sensors, both hetero- 
geneous and homogenous, could be used, either within 
the same device or working in conjunction with each oth- 
er, as is known in the art. 

[0062] As part of the system 200, the database 17 
45 stores patient care records 205 for each individual pa- 
tient to whom remote patient care is being provided. 
Each patient care record 205 contains normal patient 
identification and treatment profile information, as well 
as medical history, medications taken, height and 
so weight, and other pertinent data (not shown). The pa- 
tient care records 205 consist primarily of monitoring 
sets 206 storing device and derived measures (D&DM) 
sets 207 and quality of life and symptom measures 
(QOLM) sets 208 recorded and determined thereafter 
55 on a regular, continuous basis. The organization of the 
device and derived measures sets 205 for an exemplary 
cardiac patient care record is described above with ref- 
erence to FIGURE 5. The organization of the quality of 
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life and symptom measures sets 208 is further de- 
scribed below with reference to FIGURE 14. 
[0063] Optionally, the patient care records 205 can 
further include a reference baseline 209 storing a spe- 
cial set of device and derived reference measures sets 5 
21 0 and quality of life and symptom measures sets 211 
recorded and determined during an initial observation 
period, such as described in the related, commonly- 
owned U.S. Patent application, Serial No. 

, entitled "System And Method For 10 

Determining A Reference Baseline Of Individual Patient 
Status For Use In An Automated Collection And Analy- 
sis Patient Care System," filed December 31 , 1 999. Oth- 
er forms of database organization are feasible. 
[0064] Finally, simultaneous notifications can also be is 
delivered to the patient's physician, hospital, or emer- 
gency medical services provider 212 using feedback 
means similar to that used to notify the patient. As de- 
scribed above, the feedback could be by electronic mail 
or by automated voice mail or facsimile. The feedback 20 
can also include normalized voice feedback, such as de- 
scribed in the related, commonly-owned U.S. Patent ap- 
plication, Serial No. , entitled "Sys- 
tem And Method For Providing Normalized Voice Feed- 
back From An Individual Patient In An Automated Col- 25 
lection And Analysis Patient Care System," filed Decem- 
ber 31, 1999. 

[0065] FIGURE 13 is a block diagram showing the 
analysis module 53 of the server system 16 of FIGURE 
1 2. The peer collected measures sets 60 and sibling col- 30 
lected measures sets 61 can be organized into site spe- 
cific groupings based on the sensor from which they 
originate, that is, implantable medical device 202, exter- 
nal medical device 203, or multiple sensors 204a, 204h. 
The functionality of the analysis module 53 is augment- 35 
ed to iterate through a plurality of site specific measures 
sets 215 and one or more disorders. 
[0066] As an adjunct to remote patient care through 
the monitoring of measured physiological data via im- 
plantable medical device 202, external medical device *o 
203 and multiple sensors 204a, 204b, quality of life and 
symptom measures sets 208 can also be stored in the 
database 1 7 as part of the monitoring sets 206. A quality 
of life measure is a semi-quantitative self-assessment 
of an individual patient's physical and emotional well- *s 
being and a record of symptoms, such as provided by 
the Duke Activities Status Indicator. These scoring sys- 
tems can be provided for use by the patient 11 on the 
personal computer 18 (shown in FIGURE 1) to record 
his or her quality of life scores for both initial and periodic so 
download to the server system 16. FIGURE 14 is a da- 
tabase schema showing, by way of example, the organ- 
ization of a quality of life and symptom measures set 
record 220 for care of patients stored as part of a patient 
care record 205 in the database 17 of the system 200 55 
of FIGURE 12. The following exemplary information is 
recorded for a patient: overall health wellness 221 , psy- 
chological state 222, chest discomfort 223, location of 


chest discomfort 224, palpitations 225, shortness of 
breath 226, exercise tolerance 227, cough 228, sputum 
production 229, sputum color 230, energy level 231 , 
syncope 232, near syncope 233, nausea 234, diaphore- 
sis 235, time of day 91 , and other quality of life and 
symptom measures as would be known to one skilled in 
the art. 

[0067] Other types of quality of life and symptom 
measures are possible, such as those indicated by re- 
sponses to the Minnesota Living with Heart Failure 
Questionnaire described in E. Braunwald, ed., "Heart 
Disease-A Textbook of Cardiovascular Medicine," pp. 
452-454, W.B. Saunders Co. (1997). Similarly, function- 
al classifications based on the relationship between 
symptoms and the amount of effort required to provoke 
them can serve as quality of life and symptom meas- 
ures, such as the New York Heart Association (NYHA) 
classifications I, II, III and IV, also described in Ibid. 
[0068] The patient may also add non-device quanti- 
tative measures, such as the six-minute walk distance, 
as complementary data to the device and derived meas- 
ures sets 207 and the symptoms during the six-minute 
walk to quality of life and symptom measures sets 208. 
[0069] FIGURE 15 is a record view showing, by way 
of example, a set of partial cardiac patient care records 
stored in.the database 17 of the system 200 of FIGURE 
1 2. Three patient care records are again shown for Pa- 
tient 1, Patient 2, and Patient 3 with each of these 
records containing site specific measures sets 215, 
grouped as follows. First, the patient care record for Pa- 
tient 1 includes three site specific measures sets A, B 
and C, corresponding to three sites on Patient Vs body. 
Similarly, the patient care record for Patient 2 includes 
two site specific measures sets A and S, corresponding 
to two sites, both of which are in the same relative po- 
sitions on Patient 2s body as the sites for Patient 1. Fi- 
nally, the patient care record for Patient 3 includes two 
site specific measures sets A and D, also corresponding 
to two medical device sensors, only one of which, Site 
A, is in the same relative position as Site A for Patient 
1 and Patient 2. 

[0070] The analysis module 53 (shown in FIGURE 13) 
performs two further forms of comparison in addition to 
comparing the individual measures for a given patient 
to other individual measures for that same patient or to 
other individual measures for a group of other patients 
sharing the same disease-specific characteristics or to 
the patient population in general. First, the individual 
measures corresponding to each body site for an indi- 
vidual patient can be compared to other individual 
measures for that same patient, a peer group or a gen- 
eral patient population. Again, these comparisons might 
be peer-to-peer measures projected over time, for in- 
stance, comparing measures for each site, A, B and C, 
for Patient /, X^,*;,*;, X^.*. ,*~c. 

*n.2/|. - X n b > X -.* X '» 
X fr1 X n-i, , x .-u , X^fli x * u > x * s ... X 0 „, x o, , ; 
X xx- X < x , x . X « x . x . 
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X Qc x 6 c , x o c ; comparing comparable measures for Site 
A for the three patients, X nA , , , X^ A% , x ..i , 
*n-2>v *-i> Jr - - ^i; or comparing the indi- 

vidual patient's measures to an average from the group. 
Similarly, these comparisons might be sibling-to-sibling 5 
measures for single snapshots, for instance, comparing 
comparable measures for Site A for the three patients, 
X nA , , , Y nA , K .; , v .; , and Z nA , , or comparing 
those same comparable measures for Site A projected 
over time, for instance, X nA , Y nA , Y . A , y .; , w 

Z nA *.J.:, X^ A *„. Cf V r n . lA v .-.:, y -c, 

Z n-1 A Z -'- Z -':. *n-2 A V n-2i l /- , -» y - 8 -« 
Z n-2>v * : « » Z " ■ - *0>*' ^ ' *0/i» • Y < ' and 

\. z »;. Other forms of site-specific comparisons, in- 
cluding comparisons between individual measures from 
non-comparable sites between patients, are feasible. 
[0071] Second, the individual measures can be com- 
pared on a disorder specific basis. The individual meas- 
ures stored in each cardiac patient record can be logi- 
cally grouped into measures relating to specific disor- 
ders and diseases, for instance, congestive heart fail- 
ure, myocardial infarction, respiratory distress, and atri- 
al fibrillation. The foregoing comparison operations per- 
formed by the analysis module 53 are further described 
below with reference to FIGURES 17A-17B. 
_ [0072] FIGURE 16 is a Venn diagram showing, by 
way of example, peer group overlap between the partial 
patient care records 205 of FIGURE 15. Each patient 
care record 205 includes characteristics data 250, 251 , 
252, including personal traits, demographics, medical 
history, and related personal data, for patients 1 , 2 and 
3, respectively. For example, the characteristics data 
250 for patient 1 might include personal traits which in- 
clude gender and age, such as male and an age be- 
tween 40-45; a demographic of resident of New York 
City; and a medical history consisting of anterior myo- 
cardial infraction, congestive heart failure and diabetes. 
Similarly, the characteristics data 251 for patient 2 might 
include identical personal traits, thereby resulting in par- 
tial overlap 253 of characteristics data 250 and 251. 
Similar characteristics overlap 254, 255, 256 can exist 
between each respective patient. The overall patient 
population 257 would include the universe of all charac- 
teristics data. As the monitoring population grows, the 
number of patients with personal traits matching those 
of the monitored patient will grow, increasing the value 
of peer group referencing. Large peer groups, well 
matched across all monitored measures, will result in a 
well known natural history of disease and will allow for 
more accurate prediction of the clinical course of the pa- 
tient being monitored. If the population of patients is rel- 
atively small, only some traits 256 will he uniformly 
present in any particular peer group. Eventually, peer 
groups, for instance, composed of 1 00 or more patients 
each, would evolve under conditions in which there 
would be complete overlap of substantially all salient da- 
ta, thereby forming a powerful core reference group for 
any new patient being monitored. 


[0073] FIGURES 17A-17B are flow diagrams show- 
ing a method for automated collection and analysis of 
regularly retrieved patient information for remote patient 
care 260 in accordance with a further embodiment of 
the present invention. As with the method 90 of FIGURE 
7, this method is also implemented as a conventional 
computer program and performs the same set of steps 
as described with reference to FIGURE 7 with the fol- 
lowing additional functionality. As before, the patient 
care records are organized in the database 17 with a 
unique patient care record assigned to each individual 
patient (block 261). Next, the individual measures for 
each site are iteratively obtained in a first processing 
loop (blocks 262-267) and each disorder is iteratively 
analyzed in a second processing loop (blocks 268-270). 
Other forms of flow control are feasible, including recur- 
sive processing. 

[0074] During each iteration of the first processing 
loop (blocks 262-267), the collected measures sets for 
an individual patient are retrieved from the medical de- 
vice or sensor located at the current site (block 263) us- 
ing a programmer, interrogator, telemetered signals 
transceiver, and the like. The retrieved collected meas- 
ures sets are sent, on a substantially regular basis, over 
the internetwork 15 or similar communications link 
-(block 264) and periodically received by the server sys- 
tem 16 (block 265). The collected measures sets are 
stored into the patient care record 205 in the database 
17 for that individual patient (block 266). 
[0075] During each iteration of the second processing 
loop (blocks 268-270), one or more of the collected 
measures sets for that patient are analyzed for the cur- 
rent disorder (block 269), as further described below 
with reference to FIGURE 18. Finally, feedback based 
on the analysis is sent to that patient over the internet- 
work 15 as an email message, via telephone line as an 
automated voice mail or facsimile message, or by sim- 
ilar feedback communications link (block 97), as further 
described above with reference to FIGURE 11. 
[0076] FIGURE 18 is a flow diagram showing a rou- 
tine for analyzing collected measures sets 270 for use 
in the method 260 of FIGURES 17A-17B. The purpose 
of this routine is to make a determination of general pa- 
tient wellness based on comparisons and heuristic 
trends analyses of the device and derived measures 
and quality of life and symptom measures in the patient 
care records 205 in the database 17. A first collected 
measures set is selected from a patient care record in 
the database 1 7 (block 290). The selected measures set 
can either be compared to other measures originating 
from the patient care record for the same individual pa- 
tient or to measures from a peer group of disease spe- 
cific patients or for the patient population in general 
(block 291). If the first collected measures set is being 
compared within an individual patient care record (block 
291 ), the selected measures set can either be compared 
to measures from the same site or from another site 
(block 292). If from the same site (block 292), a second 
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collected measures set is selected for the current site 
from that patient care record (block 293). Otherwise, a 
second collected measures set is selected for another 
site from that patient care record (block 294). Similarly, 
if the first collected measures set is being compared s 
within a group (block 291), the selected measures set 
can either he compared to measures from the same 
comparable site or from another site (block 295). If from 
the same comparable site (block 295), a second collect- 
ed measures set is selected for a comparable site from 10 
another patient care record (block 296). Otherwise, a 
second collected measures set is selected for another 
site from another patient care record (block 297). Note 
the second collected measures set could also contain 
averaged measures for a group of disease specific pa- 15 
tients or for the patient population in general. 
[0077] Next, if a sibling measures comparison is to be 
made (block 298), the routine for comparing sibling col- 
lected measures sets is performed (block 105), as fur- 
ther described above with reference to FIGURE 9. Sim- 20 
ilarly, if a peer measures comparison is to be made 
(block 299), the routine for comparing sibling collected 
measures sets is performed (block 107), as further de- 
scribed above with reference to FIGURES 1 0A and 1 0B. 
[0078] Finally, a patient status indicator is generated 25 
(block 300), as described-above with reference to FIG * 
URE 8. In addition, the measures sets can be further 
evaluated and matched to diagnose specific medical 
disorders, such as congestive heart failure, myocardial 
infarction, respiratory distress, and atrial fibrillation, as 30 
described in related, commonly-owned U.S. Patent ap- 
plications, Serial No. 09/441,623, filed November 16, 
1999; Serial No. 09/441,612, filed November 16, 1999; 
Serial No. 09/442, 125, filed November 16, 1999; and 
Serial No. 09/441,613, filed November 16, 1999. In ad- 35 
dition, multiple near-simultaneous disorders can be or- 
dered and prioritized as part of the patient status indi- 
cator as described in the related, commonly-owned U. 
S. Patent application, Serial No. 09/441,405, filed No- 
vember 16, 1999. 40 


Claims 

1 . A system (1 0) for automated collection and analysis *s 
of regularly retrieved patient information for remote 
patient care, comprising: 

a network server (31 ) receiving a set (50) of col- 
lected measures retrieved on a substantially so 
regular basis from a medical device (12) having 
a sensor for monitoring at least one physiolog- 
ical measure (71 -78) or quality of life measure 
(211 ) of an individual patient (11 ), the collected 
measures set (50) comprising individual meas- 
ures which each relate to patient information re- 
corded by the medical device; 
a database (17) coupled to the network server 


(31 ) and storing the collected measures set into 
a patient care record for the individual patient 
within the database organized to store one or 
more patient care records which each comprise 
a plurality of the collected measures sets; and 
an application server (35) coupled to the data- 
base (1 7) and analyzing one or more of the col- 
lected measures sets in the patient care record 
for the individual patient relative to one or more 
other collected measures sets stored in the da- 
tabase to determine a patient status indicator 
(54). 

2. A system according to Claim 1 , further comprising: 

the network server (31 ) receiving a set of quality 
of life measures recorded by the individual pa- 
tient; 

the database (17) storing the collected quality 
of life measures set (211 ) into the patient care 
record (205) for the individual patient within the 
database; and 

the application server (35) determining a 
change in patient status by comparing at least 
one recorded quality of life measure to at least 
one other corresponding recorded quality of life" 
measure. 

3. A system according to Claim 1 , further comprising: 

the network server (31) repeatedly receiving 
one or more collected measures sets (50) 
which are each recorded by a sensor which 
monitors at least one physiological measure of 
the individual patient, each such sensor moni- 
toring a site within the individual patient unique 
from the site monitored by any other such sen- 
sor; 

the database (17) storing each collected meas- 
ures set (50) organized by specific site into the 
patient care record for the individual patient 
within the database; and 
the application server (35) analyzing one or 
more of the site specific collected measures 
sets (215) in the patient care record for each 
site within the individual patient relative to one 
or more other site specific collected measures 
sets (215) stored in the database to determine 
a patient status indicator (54). 


4. A system according to Claim 3, wherein the one or 
more site specific collected measures sets (215) 
and the one or more other site specific collected 
measures sets (21 5), both store measures collect- 

55 ed from the same relative site, or both store meas- 
ures collected from a different site. 

5. A system according to Claim 3, the application serv- 
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er (35) further comprising: 

a comparison module (62) comparing an ini- 
tial measure selected from the one or more site spe- 
cific collected measures sets (215) to a sibling 
measure (61), or to a peer measure (60), selected s 
from the one or more other site specific collected 
measures sets (215); the initial measure and the 
sibling measure (61 ) both relating to the same type 
of patient information, or the initial measure relating 
to a different type of patient information than the io 
peer measure (60). 

A system according to Claim 3, the application serv- 
er further comprising: 

15 

a derivation module (63) determining an initial 
derived measure using at least one measure 
selected from the one or more site specific col- 
lected measures sets (215) and determining a 
sibling derived measure using at least one 20 
measure selected from the one or more other 
site specific collected measures sets, the initial 
derived measure and the sibling derived meas- 
ure both relating to the same type of derived 
patient information; and 25 
a comparison module (62) comparing the initial 
derived measure to the sibling derived meas- 
ure. 

A system according to Claim 3, the application serv- 30 
er (35) further comprising: 

a derivation module (63) determining an initial 
derived measure and/or a peer derived meas- 
ure using at least one measure selected from 35 
the one or more other site specific collected 
measures sets (215); and 
a comparison module (62) comparing one of, 
an initial measure selected from the one or 
more site specific collected measures sets *o 
(215), or the initial derived measure, to one of 
a peer measure selected from the one or more 
site specific collected measures sets (215), or 
the peer derived measure; the initial measure 
or initial derived measure relating to a different *5 
type of patient information than the patient in- 
formation to which the peer or peer derived 
measure relates. 

An system according to Claim 1 , further comprising: so 

the database (17) further storing a reference 
baseline (209) comprising recorded measures 
which each relate to patient information record- 
ed during an initial time period and comprise 55 
either medical device measures or derived 
measures calculable therefrom; and 
a database module (51) obtaining at least one 


of the at least one recorded measure and the 
at least one other recorded measure from the 
retrieved reference baseline. 

9. A system according to Claim 3, wherein the one or 
more other site specific collected measures sets 
(215), 

are stored in the patient care record for the in- 
dividual patient for whom the patient care indi- 
cator (54) has been determined, 

or are stored in the patient care records for a 
group of one or more other individual patients. 

10. A system according to Claim 1 , further comprising: 

a collection client (14) communicatively inter- 
posed between the medical device (12) and net- 
work server (31 ), the collection client retrieving the 
collected measures set (50) and downloading the 
collected measures set from the collection client in- 
to a network server. 

1 1 . A system according to Claim 1 , the application serv- 
er (35) further comprising: 

a feedback module (55) providing tiered feed- 
back comprising: 

at a first level of feedback (150,151), commu- 
nicating an interpretation of the patient status 
indicator (54) to the individual patient (11 ); 
at a second level of feedback (152,153), com- 
municating a notification of potential medical 
concern based on the patient status indicator 
to the individual patient; 
at a third level of feedback (154,155), commu- 
nicating a notification of potential medical con- 
cern based on the patient status indicator to 
medical personnel (212) in local proximity to the 
individual patient; and 

at a fourth level of feedback (1 56, 1 57), commu- 
nicating a set of reprogramming instructions 
based on the patient status indicator to the 
medical device (12). 

12. A system according to Claim 11 , wherein the feed- 
back comprises at least one of the group consisting 
of a peer group status indicator, a historical status 
indicator, a trend indicator, a medicinal efficacy in- 
dicator, and a wellness indicator. 

13. A system according to Claim 1 , the application serv- 
er (35) further comprising an analysis module (53): 

dynamically analyzing the one or more of the 
collected measures sets (50) in the patient care 
record for the individual patient, or 
analyzing the one or more of the collected 
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measures sets (50) in the patient care record 
for the individual patient in a batch comprising 
the one or more of the collected measures sets 
in patient care records for a plurality of individ- 
ual patients. 

14. A method for automated collection and analysis of 
regularly retrieved patient information for remote 
patient care, comprising: 

periodically receiving (94) a set (50)of collected 
measures retrieved (92) on a substantially reg- 
ular basis from a medical device (12) having a 
sensor for monitoring at least one physiological 
measure (71-78) or a quality of life measure 
(21 1 ) of an individual patient (11), the collected 
measures set comprising individual measures 
which each relate to patient information record- 
ed by the medical device; 
storing (95) the collected measures set into a 
patient care record for the individual patient 
within a database (17) organized (91) to store 
one or more patient care records which each 
comprise a plurality of the collected measures 
sets; and 

analyzing (96) one or more of the collected 
measures sets in the patient care record for the 
individual patient relative to one or more other 
collected measures sets stored in the database 
to determine a patient status indicator (54). 

15. A method according to Claim 14, further compris- 
ing: 
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analyzing (269) one or more of the site specific 
collected measures sets (215) in the patient 
care record for each site within the individual 
patient relative to one or more other site spe- 
cific collected measures sets stored in the da- 
tabase to determine a patient status indicator 
(54). 

17. A method according to Claim 16, wherein 

the one or more site specific collected meas- 
ures sets (215) and the one or more other site 
specific collected measures sets both store 
measures collected from the same relative site, 
or 

the one or more site specific collected meas- 
ures sets (215) and the one or more other site 
specific collected measures sets both store 
measures collected from a different site. 

18. A method according to Claim 16, the operation of 
analyzing the one or more site specific collected 
measures sets further comprising: 

comparing an initial measure selected from 
the one or more site specific collected measures 
sets (215) to a sibling measure (61), or to a peer 
measure (60), selected from the one or more other 
site specific collected measures sets (215); the ini- 
tial measure and the sibling measure (61 ) both re- 
lating to the same type of patient information, or the 
initial measure relating to a different type of patient 
information than the peer measure (60). 


receiving a set of quality of life measures re- 
corded by the individual patient; 
storing the collected quality of life measures set 
(211) into the patient care record (205) for the 
individual patient within the database (17); and 


one physiological measure of the individual pa- 
tient (201), each such sensor monitoring a site 
within the individual patient unique from the site 
monitored by any other such sensor; 
storing (266) each collected measures set or- 
ganized (261 ,262) by specific site into the pa- 
tient care record for the individual patient within 
the database (17); and 


35 19. A method according to Claim 16, the operation of 
analyzing the one or more site specific collected 
measures sets further comprising the application 
server further comprising: 

determining an initial derived measure using at 
least one measure selected from the one or 
more site specific collected measures sets 
(215) and determining a sibling derived meas- 
ure using at least one measure selected from 
the one or more other site specific collected 
measures sets, the initial derived measure and 
the sibling derived measure both relating to the 
same type of derived patient information; and 
comparing the initial derived measure to the 
sibling derived measure. 

20. A method according to Claim 16, the operation of 
analyzing the one or more site specific collected 
measures sets further comprising: 

55 

determining an initial derived measure and/or 
a peer derived measure using at least one 
measure selected from the one or more other 


determining a change in patient status by com- *o 
paring at least one recorded quality of life 
measure to at least one other corresponding re- 
corded quality of life measure. 

16. A method according to Claim 14, further compris- 4 $ 
ing: 

repeatedly receiving (265) one or more collect- 
ed measures sets which are each recorded by 
a sensor (202,203,204) which monitors at least 50 


15 


■ 


29 


EP 1 057 448 A1 


30 


site specific collected measures sets (21 5); and 
comparing one of, an initial measure selected 
from the one or more site specific collected 
measures sets (215), or the initial derived 
measure, to one of a peer measure selected s 
from the one or more site specific collected 
measures sets (215), orthe peer derived meas- 
ure; the initial measure or initial derived meas- 
ure relating to a different type of patient infor- 
mation than the patient information to which the 10 
peer or peer derived measure relates. 


puter, network or server system, is adapted to per- 
form a method as claimed in any one of claims 14 
to 23. 

25. A computer-readable storage medium, having en- 
coded thereon a computer program according to 
claim 24. 


21. A method according to Claim 14, further compris- 
ing: 

15 

retrieving a reference baseline (209) compris- 
ing recorded measures which each relate to pa- 
tient information recorded during an initial time 
period and comprise either medical device 
measures or derived measures calculable 20 
therefrom; and 

obtaining at least one of the at least one record- 
ed measure and the at least one other recorded 
measure from the retrieved reference baseline. 

25 

22. A method according to Claim 16, wherein the one 
or more other site specific collected measures sets 
(215), 


are stored in the patient care record for the in- 30 
dividual patient for whom the patient care indi- 
cator (54) has been determined, 

or are stored in the patient care records for a 
group of one or more other individual patients. 35 


23. A method according to Claim 14, further compris- 
ing: 

providing tiered feedback comprising: 

40 

at a first level of feedback (150,151), commu- 
nicating an interpretation of the patient status 
indicator (54) to the individual patient (11); 
at a second level of feedback (152,153), com- 
municating a notification of potential medical 
concern based on the patient status indicator 
to the individual patient; 
at a third level of feedback (154,155), commu- 
nicating a notification of potential medical con- 
cern based on the patient status indicator to so 
medical personnel (21 2) in local proximity to the 
individual patient; and 

at a fourth level of feedback (1 56,1 57), commu- 
nicating a set of reprogramming instructions 
based on the patient status indicator to the 55 
medical device (12). 

24. A computer program which when running on a com- 
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